如果你在Google搜尋Hyperledger你會得到很多個關鍵字,「超級帳本計畫」、「IBM」、「Linux基金會」、「Hyperledger區塊鏈聯盟」、「Intel」、「Hyperledger Fabric」、「Hyperledger Sawtooth」等....
對我來說,這些關鍵字足以讓我搞不清楚Hyperledger到底是什麼了XD,這些都直到實際實作之後才比較清楚,根據維基百科的資料
「Hyperledger 是一個旨在推動區塊鏈跨行業應用的開源專案, 由 Linux基金會在2015年12月主導發起該專案, 成員包括金融,銀行,物聯網,供應鏈,製造和科技行業的領頭羊。」
數位時代網站上有篇文章也有提到
「與比特幣、以太坊區塊鏈互別苗頭,IBM力挺Hyperledger區塊鏈聯盟。Hyperledger已經有122個會員,是全球最大的區塊鏈聯盟。」
那Hyperledger到底是一個專案,由Linux基金會維護 ; 還是一個專案,由Hyperledger區塊鏈聯盟122個會員組織一起維護呢?還是...(好繞口)
簡單來說,Hyperledger就像是一個復仇者聯盟的概念,在這聯盟底下的專案各自為政(像超級英雄獨立電影),也共同合作,雖各自為政,但與計畫內其他專案都是能夠共同整合的(部分專案),所以我們可以這樣說,Hyperledger是好幾個專案的集合體,這些專案由聯盟成員發起,不一定能互相連通(因為使用場景不一定是相同的),例如Hyperledger Fabric 跟 Hyperledger Sawtooth都是分布式帳本解決方案,但使用場景的出發點就有所不同,後面我們會做簡單對比
這個系列文章我會聚焦在Fabric這個專案上,Fabric是一個由Linux基金會主導的Hyperledger專案,同時IBM是Fabric專案中貢獻程式碼數量最多的成員,在開始系列文章之前我也會簡單敘述一下其他的Hyperledger專案,以及Fabric跟其他專案之間的差異。
目前Hyperledger已經發展出九個正式專案和50多個衍伸出來的相關模組專案,根據github上的資料可以整理出下圖(截至今天2018.10.17,排除掉已封存專案)
另外,在官網上的一張圖明確地將所有專案列了出來,Framework跟Framework之間不一定要互相支援整合(有的還是競爭關係),在技術選用上還是以應用場景的差異為主要考量。
*Hyperledger計畫中有部分專案目前仍在孵化發展中,也因此本文資訊具有時效性,特此聲明。
本文將對Frameworks部分做一個簡明介紹
Hyperledger Burrow 源自於以太坊框架,是一個需要授權許可才能連接區塊鏈網路的技術,這是因為以太坊在很多方面不見得適合企業端和商業需求(可能需要迎合當地法規),Burrow採用模組化設計(所以能按照需求選用不同的共識算法,目前支援PBFT、SBFT以及PoET),相容以太坊虛擬機(EVM),所以可以直接執行ETH的智能合約,Burrow由Monex與Intel共同維護,目前的資料其實不多,但看起來Burrow是想成為一種通用的智能合約引擎,並成為Hyperledger計畫中的跨鏈解決方案。
本系列主題,也是Hyperledger專案中少數已發布正式版的專案,截至目前為止的版本為1.3,但本系列文章會採用1.1版作為教學主體,這個系列寫完之後預計會再補充內容到1.3版,對於初次接觸Hyperledger Fabric的人來說,1.1版是個好的開始,有興趣的人從這個版本開始熟悉後再更新就更能得心應手,Fabric專案是Hyperledger的核心項目,以至於一般提到Hyperledger都會以為講的是Hyperledger Fabric,但這是一種常見誤解,Fabric是Hyperledger其中一個專案,由此可看出Fabric在整個計畫裡的重要性。
Fabric本質上是一種分布式帳本解決方案,採用模組化的架構設計,所以在Fabric中我們是可以選擇要使用哪一種共識算法的,這在後面文章會再深入提到,Fabric專案最初由IBM開發,目前由Linux基金會共同維護。
Hyperledger Indy專案是一個很有趣的技術,該計畫希望實現一種去中心化身份認證工具,因為現在的人可能擁有多種身份,你可能是某公司的員工、某台車的車主、某位小朋友的家長、健保投保人等等身份,這些身份目前都是各自獨立的系統,Indy試圖透過區塊鏈帳本整合所有的身份資訊,並且提供一個安全的存取環境,確保隱私問題能夠獲得保證。
Hyperledger Iroha專案也是一個分布式帳本技術,由日本的Soramitsu, Hitachi,以及NTT Data、Colu等公司提出,目前由Linux基金會管理,主打的特色就是Mobile First(行動優先),這個計畫仍然在孵化階段,採用C++開發,共識算法為BFT。
Hyperledger Sawtooth由Intel提出,目前由Linux基金會管理,跟Fabric一樣是分布式帳本技術,也是一個已經釋出正式版的專案,因此常常被拿來跟Fabric比較,Sawtooth提供了一個新的共識算法,計時驗證(PoET),除了共識算法之外,最大特色還是Sawtooth提供了更細微的權限控制、可執行以太坊智能合約,並且支援平行計算,雖然目前我對Sawtooth技術還沒有很熟悉,但在嘗試對比Fabric後我對於Sawtooth非常有興趣,未來我也計畫要針對Sawtooth更近一步研究,有機會的話我會再撰文介紹,下面我會對比一下Fabric跟Sawtooth的差異。
對比項目 | Sawtooth | Fabric |
---|---|---|
操作模式 | Permissioned | Permissioned or Private |
共識演算法 | Proof of Elapsed Time | 允許使用者選擇共識演算法 |
智能合約 | GO,JAVA | GO,JAVA |
貨幣 | 無 | 無或者藉由鏈碼(chaincode)創建 |
主導組織 | Linux基金會 | Linux基金會 |
平行計算支援 | 有 | 無 |
關於操作模式的說明,以下內容屬於筆者個人的體會,為求謹慎,幾經考量後決定先將表格內換回英文,並且會在理解更多之後回來更新說明的內容~謝謝各位
Sawtooth在權限的設計上定義了角色和權限,接近於傳統應用的RBAC模型(Role-based access control),因此在應用上比較容易靈活運用,相較之下Fabric的MemberShip Provider(MSP)雖然強大,但操作上真的比較難懂(因為是基於事務設計),且兩者發展方向也不同,所以這也成為了我們在選用技術時的一個重要判斷基準。
Fabric是純粹為了聯盟鏈(有權限)而生,通過它獨特的通道(Channel)概念以及MemberShip Provider(MSP)服務設計,在聯盟鏈的應用方面則能做到比Sawtooth更精細的權限控制,可以說最適合B2B的應用場景了,關於MSP跟通道(Channel)我們會用另外的獨立篇幅做介紹
最初步的判斷方式是,如果B2B選Fabric,B2B2C選Sawtooth,然後再來考慮後面的,我只能說,雖然Fabric跟Sawtooth都是企業級解決方案,但發展的路徑各有不同,我們在考慮採用哪種技術之前要依據應用場景來挑選最適合的解決方案。
前面我雖然用B2B跟B2B2C來做簡單的二分法,但實際上絕對沒這麼簡單,還得考慮到共識算法、區塊鏈網路的應用範圍、安全性等等的問題,再說,在這鐵人賽的最後幾篇我預計要探討一個個案,該個案就是混用Hyperledger Fabric以及Stellar公鏈所搭建的區塊鏈應用,一樣也能開發B2B2C的應用,所以說Fabric還是一個值得投資的技術的(XD)
或許之後可以再針對「選擇技術」的部分另外再撰文做說明,也歡迎大家有興趣能一起來交流,但為了避免偏離主題,本系列文章在之後的篇幅都將只針對Fabric做探討及說明。
在了解Hyperledger計畫是什麼以及可以做什麼之後,下一篇將開始針對Fabric做介紹,第一步是安裝環境以及編譯工具,建議需要有Docker的使用經驗,這樣會比較好上手喔!